Over the years, a variety of techniques have been used for executing multiple software modules within a computer system. Early computer systems could execute multiple software programs, but they could only execute one program at a time. Such computers might load one program into memory and execute it to completion or other termination, before proceeding to a subsequent program that would then be loaded into memory and executed. As another example, various multitasking operating systems (OSs) enable multiple programs (or selected portions thereof) to be loaded into memory at one time and executed in an alternating manner, according to a scheduling algorithm. Also, some processors include multithreading capabilities, which enable multiple threads of one or more programs to be executed simultaneously on a single processor. Finally, multiprocessor computer systems have also become commonplace, in which each of the multiple processors can execute one or more threads all at the same time.
Such computer systems generally attempt to isolate the code and data of the different software modules within the computer system from each other, so that, for example, one software module cannot interfere with the execution of another software module by altering its code or data. Such isolation may be provided for code and/or data that is stored on a hard drive (or other secondary data storage means) and/or that is resident in main memory (or other primary data storage means).
As one example of the isolation of code and data, many systems implement a virtual addressing mechanism, in which different software modules within the system have different virtual address spaces, with each virtual address space generally being mapped to different portions of the physical address space of the computer system, so that the virtual addresses of a given software module are generally only mapped to physical addresses that contain the code or data of that particular software module. A given software module may attempt to access every memory location in its own virtual address space, accessing every memory location to which it has access, and will still only be able to access its own code and data (assuming that there is no shared memory). Thus, providing a virtual addressing mechanism provides some isolation between the code and data of multiple software modules in a computer system. Various other protection mechanisms may also be implemented in such computer systems to isolate the code and/or data of multiple software modules from one another.
FIG. 1 illustrates a simple computer system 2A having multiple software modules. The computer system 2A includes system hardware 100A, an OS 20A, a first application 40A and a second application 40B. The system hardware 100A may be conventional hardware based on, for example, the x86 platform, and the OS 20A may be, for example, a Windows OS or a Linux OS. The applications 40A and 40B may be any applications designed to run on the system hardware 100A and the OS 20A. The OS 20A also includes a set of drivers 29A, which may be conventional drivers for the OS 20A, possibly including one or more drivers from a company that is different from the OS vendor (a third party vendor).
The OS 20A, in conjunction with the system hardware 100A, attempts to isolate the code and data of the applications 40A and 40B from one another. For example, the OS 20A and the system hardware 100A may implement a virtual addressing mechanism, as described above. As illustrated in FIG. 1, implementing such a protection mechanism may be characterized as establishing an isolation barrier 80B between the applications 40A and 40B, preventing (or at least hindering) one application from accessing the code and data of the other application. There may also be some code and/or data that is shared explicitly or transparently between the applications 40A and 40B. Techniques are known for allowing such sharing of code and data, while maintaining isolation between the applications 40A and 40B. For example, the OS 20A may mark physical memory pages that contain shared code or data as read only, such as when using a copy-on-write (COW) technique. The isolation barrier 80B may be referred to as an “OS isolation barrier” because it is implemented by the OS 20A, in conjunction with the system hardware 100A. The OS 20A, again in conjunction with the system hardware 100A, also establishes an OS isolation barrier 80A between the OS 20A and all applications in the system, including the applications 40A and 40B, so that the applications are prevented (or hindered) from directly accessing the code and data of the OS 20A. In the case of a Windows or Linux OS running on an x86 platform, the OS isolation barrier 80A is established by executing the applications in the system at a supervisor privilege level to access memory pages containing the code and data of the OS 20A.
Although the Windows and Linux OSs provide adequate isolation between software modules for computer systems that contain only well designed and well behaved software modules, malicious software modules have been known to corrupt such computer systems by circumventing the protection mechanisms. In particular, such malicious software modules have been known to breach the OS isolation barriers 80B and 80A, and corrupt the code and/or data of other applications in the system, and/or of the OS itself. Numerous security vulnerabilities have been discovered in the Windows OSs and, to a lesser extent, in the Linux distributions, and many of these vulnerabilities have been exploited by hackers using different types of malicious software, such as viruses, worms, etc. Although the description in this disclosure generally relates to malicious software, it also applies to software that inadvertently has the same or similar effects as malicious software. For example, poorly designed or implemented software may inadvertently bypass protection mechanisms and corrupt the computer system.
Machine virtualization provides certain advantages in establishing OS isolation barriers and application isolation barriers. A virtual machine (VM) is a software abstraction—a “virtualization”—of an actual or an abstract physical computer system. The VM runs as a “guest” on an underlying “host” hardware platform. Guest software, such as a guest OS and guest applications, may be loaded onto the virtual computer for execution. The guest OS may, but need not be, the same as the OS or other system software running at the system level in the host. For example, a Windows OS may be run in the VM even though the OS used to handle actual I/O (input/output), memory management, etc., on the host might be a Linux OS. Also, as long as a suitable interface is provided between the VM and the host platform, a user of a VM need not even be aware that he is not using a “real” computer, that is, a system with hardware dedicated exclusively to his use. The existence of the underlying host can be made transparent to a user of the VM and to the guest software itself. The virtual computer systems described below with reference to FIG. 2, support VMs that have these characteristics.
FIG. 2 illustrates a general computer system 2B in which multiple VMs are implemented to isolate multiple software modules from one another. The computer system 2B includes system hardware 100B, which may be conventional hardware, such as hardware based on the x86 platform. The system hardware 100B may be substantially the same as the system hardware 100A of FIG. 1, or it may be substantially different. Virtualization software 200A executes on the system hardware 100B and supports a plurality of VMs, such as a first VM 300A and a second VM 300B, in a known manner. The virtualization software 200A may comprise a Virtual Machine Monitor (VMM), for example, such as a VMM as implemented in a virtualization product of VMware, Inc., Palo Alto, Calif. Such a VMM and other components of the virtualization software 200A are described in greater detail below.
In supporting the VM 300A, the virtualization software 200A virtualizes a virtual system hardware 310A, which may be based on an existing hardware platform, such as the x86 platform. An OS 20B, along with a set of drivers 29B, run on the virtual system hardware 310A. The OS 20B may be any OS designed to run on the hardware platform virtualized in the virtual hardware 310A. For example, if the virtual hardware 310A is based on the x86 platform, the OS 20B may be a Windows OS or a Linux OS. The set of drivers 29B may be conventional drivers for the OS 20B. A first application 40C and a second application 40D run on the OS 20B. The applications 40C and 40D may be any applications designed to run on the platform of the virtual hardware 310A and the OS 20B. Similar to the OS 20A of FIG. 1, the OS 20B, in conjunction with the virtual system hardware 310A, attempts to isolate the code and data of the applications 40C and 40D from one another, establishing an OS isolation barrier 80B between the applications 40C and 40D. Also similar to the OS 20A of FIG. 1, the OS 20B, again in conjunction with the virtual system hardware 310A, also establishes an OS isolation barrier 80A between the OS 20B and all applications in the VM 300A, including the applications 40C and 40D. Thus, the VM 300A may operate substantially the same as the computer system 2A, except that the virtual system hardware 310A is software abstraction of hardware, created by the virtualization software 200A, instead of physical hardware.
Virtualization software 200A supports VM 300B, including virtual system hardware 310B, OS 20C, drivers 29C, and applications 40E and 40F, in a manner similar to that of VM 300A and its corresponding component elements. Similar to OS 20B, the OS 20C, in conjunction with the virtual system hardware 310B, attempts to isolate the code and data of the applications 40E and 40F from one another, establishing an OS isolation barrier 80B between the applications 40E and 40F. Also similar to the OS 20B, the OS 20C, again in conjunction with the virtual system hardware 310B, establishes an OS isolation barrier 80A between the OS 20C and all applications in the VM 300B, including the applications 40E and 40F. Thus, VM 300B may also be substantially similar to the computer system 2A, except that the virtual system hardware 310B is virtual hardware, virtualized by the virtualization software 200A, instead of physical hardware.
The virtualization software 200A isolates VMs 300A and 300B in the computer system 2B from one another. For example, the virtualization software 200A allows software within the VM 300A to access portions of physical memory in the system hardware 310B and allows software within the VM 300B to access other portions of the physical memory. The virtualization software 200A maps attempted memory accesses from the respective VMs 300A and 300B to different portions of the physical memory, ensuring that no memory address generated by software in one VM can access code or data of another VM. In a similar manner, the virtualization software 200A maps attempted hard disk accesses from the respective VMs 300A and 300B to different portions of one or more hard disks in the system hardware 100B, ensuring that one VM cannot access the hard disk space of another VM.
The virtualization software 200A also takes other precautions to isolate the VMs 300A and 300B in the computer system 2B from one another, and from the virtualization software 200A, itself. For example, commonly assigned, U.S. Pat. No. 7,281,102, Agesen et al., “Restricting Memory Access to Protect Data when Sharing a Common Address Space”, which is incorporated herein by this reference for all purposes, describes methods that may be used to enable a VMM to occupy a portion of a linear address space of a VM, while preventing the VM from accessing the memory of the VMM.
Various other methods that may be used to enable virtualization software to coexist with VMs in a virtual computer system, while protecting or isolating the virtualization software from software within the VMs. The virtualization software 200A may also prevent software within the VMs 300A and 300B from directly accessing certain hardware resources to further isolate the VMs from one another and from the virtualization software 200A. For example, the virtualization software 200A may prevent software within the VMs 300A and 300B from directly accessing a Direct Memory Access (DMA) device to prevent the possibility that the DMA device could be used to access either the hard disk space or the memory of other VMs or of the virtualization software itself. Various other precautions may also be taken, depending on the particular implementation.
Thus, the virtualization software 200A, in conjunction with the system hardware 100B, may be said to establish a first isolation barrier 280B between the VMs 300A and 300B and a second isolation barrier 280A between the virtualization software 200A and all VMs in the computer system 2B, including the VMs 300A and 300B. The isolation barriers 280A and 280B may be referred to as “virtualization barriers” because they are implemented by the virtualization software 200A, in conjunction with the system hardware 100B. The isolation barriers 280A and 280B may also be referred to as virtualization barriers because they are established through the virtualization of hardware resources, such as the virtualization of system memory.
It is widely recognized that virtualization techniques can generally provide better security and more effective isolation between multiple software modules than general OSs provide. Thus, the virtualization barriers 280A and 280B of FIG. 2 can generally provide much better isolation between the multiple VMs 300A and 300B and the virtualization software 200A than the OS isolation barriers 80A and 80B of FIG. 1 provide between the multiple applications 40A and 40B and the OS 20A. This improved isolation can be attributed to a variety of factors, depending on the particular situation.
Although computer systems that establish multiple VMs and that run different software modules within the different VMs generally provide better isolation for the software modules than do general OSs, such virtual computer systems have other limitations. First, for example, if the software within a VM becomes corrupted by malicious software, the same problems described above relative to non-virtualized computer systems can occur within the affected VM. If the VM becomes corrupted, software modules within the particular VM may be compromised by the malicious software. In addition, critical programs, such as virus detection or prevention programs running in the VM, are often the targets of malicious attacks. In these attacks, in order to get control of the host system without detection, particularly in a hosted VM environment, the programs that protect the system are typically disabled. Relying on the host OS kernel to protect these programs may be unwise since the OS kernel exposes exploits that allow malicious code to be loaded and run at the most privileged level, thus leaving the entire system unprotected.
Accordingly it is desirable in a virtualized computer system to prevent critical programs from targeted attacked. It is further desirable to protect specific physical memory associated with such programs. It is further desirable to define the properties of the VM's physical memory to protect programs running in the VM. It is further desirable to allow programs executing both internal and external to the virtualization software to secure their code and data in memory without going through the OS kernel.